fix: resolve build failures on Linux with Clang 18 (const qualifier + OpenMP linker)#431
Closed
parthalon025 wants to merge 2 commits intomicrosoft:mainfrom
Closed
fix: resolve build failures on Linux with Clang 18 (const qualifier + OpenMP linker)#431parthalon025 wants to merge 2 commits intomicrosoft:mainfrom
parthalon025 wants to merge 2 commits intomicrosoft:mainfrom
Conversation
The function signature declares `vy` as `const void *`. After casting to `int8_t *`, assigning pointer arithmetic on that value to a non-const `int8_t * y_col` drops the const qualifier. Clang 18 rejects this with an implicit-const-conversion error; GCC and older Clang accepted it with a warning or silently. Fix: declare `y_col` as `const int8_t *`, which correctly propagates the const qualifier from the input parameter through the pointer arithmetic. Affected location: src/ggml-bitnet-mad.cpp:811 (ggml_vec_dot_i2_i8_s_Nx1)
…rors On Linux systems where both a distro-packaged clang (e.g. clang-18 from llvm.org/apt) and an alternative clang (e.g. Homebrew clang) coexist, the bare 'clang' alias may point to a build that links against a different libomp than the one installed by the OS package manager. This causes undefined-symbol linker errors at build time: undefined reference to `__kmpc_fork_call@VERSION` Root cause: each clang distribution ships its own libomp. When clang and libomp come from different distributions, the symbol versioning may not match. Distro-packaged versioned binaries (clang-18, clang-17, ...) are guaranteed to pair with the correct libomp. Fix: add _find_clang() which probes for versioned Clang/Clang++ binaries (18, 17, 16, 15) before falling back to the bare 'clang'/'clang++' alias. The probe is Linux-only; macOS and Windows are unaffected. This fixes setup_env.py --hf-repo builds on Ubuntu 22.04/24.04 with clang-18 installed via `apt install clang-18 libomp-18-dev`. Affected location: setup_env.py compile() -- CMake -DCMAKE_C_COMPILER / -DCMAKE_CXX_COMPILER
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two related build failures on Linux systems with Clang 18.
Fix 1 —
constqualifier ony_col(ggml-bitnet-mad.cpp:811)Problem:
ggml_vec_dot_i2_i8_s_Nx1receivesvyasconst void *. Pointer arithmetic on the cast value yieldsconst int8_t *, but the local variabley_colwas declared asint8_t *, silently dropping the const qualifier. Clang 18 rejects this as an error; GCC and older Clang accepted it silently.Fix: Declare
y_colasconst int8_t *to correctly propagate the const qualifier. Zero behavioral change.Fix 2 — Auto-detect versioned Clang on Linux (
setup_env.py)Problem: On Linux systems where both a distro-packaged
clang-18(apt/llvm.org) and an alternativeclang(e.g. Homebrew) are installed, the bareclangalias may resolve to a binary that links against a differentlibompthan the one installed by the OS. This causes a linker error at build time:Root cause: Each Clang distribution ships its own
libomp. Distro-packaged versioned binaries (clang-18,clang-17, ...) are guaranteed to pair with the correctlibomp.Fix: Add
_find_clang()which probes for versioned Clang/Clang++ binaries (18 → 17 → 16 → 15) on Linux before falling back to bareclang/clang++. Non-Linux platforms (macOS, Windows) are unaffected.Tested on: Ubuntu 24.04 with
apt install clang-18 libomp-18-dev, x86_64, modelFalcon3-10B-Instruct-1.58bit.Checklist
setup_env.py --hf-repo tiiuae/Falcon3-10B-Instruct-1.58bitbuilds and runs inference successfully after both fixes